Interpretation of int (*a)[3]
Posted
by kapuzineralex
on Stack Overflow
See other posts from Stack Overflow
or by kapuzineralex
Published on 2010-02-12T08:12:28Z
Indexed on
2010/04/20
21:23 UTC
Read the original article
Hit count: 193
When working with arrays and pointers in C, one quickly discovers that they are by no means equivalent although it might seem so at a first glance. I know about the differences in L-values and R-values. Still, recently I tried to find out the type of a pointer that I could use in conjunction with a two-dimensional array, i.e.
int foo[2][3];
int (*a)[3] = foo;
However, I just can't find out how the compiler "understands" the type definition of a in spite of the regular operator precedence rules for * and []. If instead I were to use a typedef, the problem becomes significantly simpler:
int foo[2][3];
typedef int my_t[3];
my_t *a = foo;
At the bottom line, can someone answer me the questions as to how the term int (*a)[3] is read by the compiler? int a[3] is simple, int *a[3] is simple as well. But then, why is it not int *(a[3])?
EDIT: Of course, instead of "typecast" I meant "typedef" (it was just a typo).
© Stack Overflow or respective owner